A hitchhiker’s guide to product management

What this guide is about

This resource is meant as an introductory guide for people who are either new or aspiring to break into the product management field. It’s focused on PM work at tech startups, but many of the points can be applied across industries. The guide includes some of the best resources from across the internet that I found over the years. There are great contents out there, but they are surrounded by a hell of a lot more noise. What this guide will hopefully do for you is to cut through all the noise and accelerate the knowledge acquisition phase of your learning. It’s not meant to be an exhaustive list of everything you need to know about product, nor will you become a great product manager after reading this. Life isn’t so simple. Think of it as a giant list of what I wish I had known when I first started product management. I hope this helps!

If you find this guide interesting, please subscribe to the blog as well. I’ll be writing separate posts every month that deep dive into specific aspects of product management. you can also find me on twitter @yilunzh.

Table of Content

Introduction

Basic Principles

Hard Skills

Soft Skills

Introduction

Product management is both easy and hard. It’s easy because being one doesn’t require any specialized skills. If you can think, read and write like a competent human being, you can become a product manager.

Product management is also very hard. A product manager is a jack of all trades. While you don’t have to be an expert on any single subject, you absolutely need to be competent in many different areas. The problem is that it takes time to learn a new skill from scratch. Malcolm Gladwell famously said that it takes 10,000 hours of deliberate practice to become world class in any field. Assuming that learning a new skill is your full time job (40 hr/week), that is equivalent to 5 years of your life. At first glance, it seems like product managers are geniuses. They are outliers that can grasp new concepts in days instead of weeks, learn new skills in months instead of years. They are the kids you knew in college who partied harder than you ever did yet still managed to get 4.0s across the board.

While I wish that’s true (I would be flattered), it is simply not the case. I sort of lied when I said that product managers don’t have any specialized skill. They do. All the great ones I know are able to absorb and apply new information at an abnormal rate. In the beginning, I thought they were simply smarter than me. Overtime, I came to realize that like any other skill, it can be learned.

People often think that the pace of learning is linear. For example, if it takes 5 years to master something, then it must take ~2.5 years to be average and 4 years to be good. In reality, this is not the case (in a good way). I want to highlight 2 key points here:

  1. The 80/20 rule applies to learning. It’s far easier to go from incompetent to good than from good to great. With the right resources and techniques in place, it only takes 20% of the time/effort to get 80% of mastery. I believe that a great product manager doesn’t need to be a master at everything, only competent to good (50-80% mark).
  2. Learning takes the form of an S-curve. In the beginning, it takes a lot of time to just get the basic theory down. You feel like you are spending a lot of effort for very little gain. This is when many people drop off, because they feel like they are not making any progress. Keep in mind though, nothing worthwhile is easy. I would argue that this is the time for you to double down and power through it. Once you get past the initial knowledge acquisition phase and start integrating them into your knowledge bank, you will notice that the rate of learning becomes exponential.

There is a fair bit of content in this guide. They are categorized and ordered in a way that I think make the most sense. Feel free to skip around and explore as you see fit 🙂

Back to Top

Basic Principles

This section is to answer the most common questions people have about product management and introduce the core principles that I think a PM should know. This is the basics of the basics, which is fine. We all have to start from somewhere 🙂

Core philosophies

To set the table, I think it’s best to take a look at what other people say about PM. I also put an old blog post I wrote in here as well (shameless plug!). I hope you find it at least somewhat insightful.

Questions to ponder:

  • What’s the role of a PM? How does it fit within the larger team/organization?
  • How does a PM spend his/her day?
  • What makes a good PM?
  • What makes a shitty PM?

Readings:

Exercise:

  • Reach out to someone who is currently a PM and ask him for a piece of specific advice on a topic you want to learn about.

Back to Top

Understand customers

If there’s one thing you need to do better than anyone else at the company, it’s to understand your customers. To the engineers and designers, you are the voice of the customer. In order to clearly articulate the requirements to your team, you need to understand their pain points and needs more than anyone else.

This section doesn’t get into any of the tactical advice about conducting customer research (that’ll come later). It’s more about building a foundation and a framework in your mind about how to approach the problem.

Questions to ponder:

  • What should you focus on when trying to understand your customer?
  • How should you treat a feature request from existing users?
  • Why is cycle time for learning important?

Readings:

Exercise

  • If you work in a B2C company, listen to some customer service calls and writeup your learnings.
  • If you work in a B2B company, reach out to a few customers and get their feedback on your product. Again, writeup your learnings.

Back to Top

Discover product-market fit

Product-market fit has become quite a buzzword in recent years. I think it’s often mis-used and misunderstood. Marc Andreessen, the founder of Andreessen & Horowitz, defines it as “being in a good market with a product that can satisfy that market”. Steve Blank, who you’ll read extensively later, refer to it as the step between customer validation and customer creation. To me, finding product-market fit means solving a big enough problem for a subset of people that they are willing to pay you money AND tell everyone how great you are.

Regardless of how you word it, the core idea behind product-market fit is to understand the conditions that your product must meet in order to become a viable and scalable business (i.e. Is the market big enough? Is the problem painful enough? Is the solution good enough? Does the economics work? etc.). These are the questions that you have to clearly articulate whenever you are pitching for resources.

Questions to ponder:

  • How do you define product market fit?
  • Why is product market fit important?
  • How do you know if you have achieved product market fit?
  • How do you find product market fit?

Readings:

Exercise:

  • Research a tech startup that’s currently growing exponentially (e.g. Uber, Airbnb, Dropbox etc.). Answer the following questions:
    • Why do you think they were able to achieve this level of growth?
    • What big hurdles did they have to overcome?
    • How did they overcome them?

Back to Top

Be bold and ambitious

This sounds a bit cliche, but it’s one of the most common traits among successful entrepreneurs and PMs I know. To be more specific:

  • They tend to have a healthy disrespect towards traditions. “Because that’s how it’s always been” is not an acceptable answer.
  • They view problems as opportunities. The bigger the problem, the more lucrative the opportunity.
  • They are inherently optimistic and have incredible confidence in their own ideas and abilities. They have so much confidence that they can’t fathom the possibility of failure.

Being bold is contagious. Peter Diamandis, the founder of X Prize, stresses the importance of launching your idea/product above the line of super credibility. His point is that the best ideas are those that are so crazy, but so amazing that people want to actively help you make it happen.

Questions to Ponder:

  • Why do people continue to underestimate human progress in the long term, even though all the science and historical data suggest otherwise?
  • How can you train yourself to break out of that habit?
  • What are some major technology trends right now? How do you think those things will change your life in 10 years?

Readings:

Exercise

  • Write about a new technology or trend you are excited about. how do you think it’ll evolve over time? What market conditions have to be met in order to make that vision a reality?

Back to Top

Hard skills

This section focuses on the fundamentals skills you need in order to become a competent product manager. By the end of this section, you should have the requisite knowledge to perform the major functions that a product manager do on a daily basis.

Requirement gathering

As a PM, requirement gathering is probably an activity you will spend the most time doing day to day. There are a lot of resources out there on how best to write user stories (some are linked in the readings below), so I wouldn’t get into the weeds here. But I do want to share some rules of thumb I follow when I’m unsure what to do:

  1. Be precise and clear
    1. Say exactly what you mean. Don’t use ambiguous terms or acronyms if you can help it. If there are acronyms, clearly define them ahead of time.
    2. Use everyday language, not big words that nobody understands. Your requirement should read like the way you explain how a product works to a smart friend.
  2. Be concise
    1. If there are sections of the requirement that feels repetitive, look to break them out and consolidate them into one section. Then, wherever that is relevant, simply call out that section. This way, the engineers is not reading duplicative information repeatedly. Moreover, whenever there is a change to the requirement (there will be lots), it will also be easier for you to change without forgetting a section. In the programming world, this practice is called keeping your code DRY. It make it more readable and maintainable. The same concept applies here.
    2. Use ample illustration, especially mockups and flowcharts to communicate complex flows.
  3. Be thorough
    1. One of the worst thing that can happen is to have your engineer read your requirement and think of an scenario that you haven’t thought of. It slows down development and kills your credibility in their eyes.

The readings below should help get you started on writing good requirements.

Questions to ponder:

  • What are some methods you can use to gather requirements?
  • What are the key components of a good requirements document?
  • How best to share your requirements with the engineering team?

Readings:

Exercise: Requirements writing

  • Think of a product idea, write the necessary requirement documents to be handed off to engineering

Back to Top

Writing

The first article in the reading below basically sums up how I feel about writing. I actually never appreciated good writing until I started building my first startup Fleetbit after college. At the time, we were building Uber like apps for the taxi companies so that they can compete against Uber. Taxi companies, in case you don’t know, are incredibly backwards. In order to educate our potential customers on this new technological trend and why that’s going to fundamentally change their business, we started an industry blog. One day, when we were in a meeting with one of the taxi company’s CEO, we noticed that all of our blog posts were printed out and sitting on his desk. Apparently he had been reading them and was planning to share them at the upcoming industry conference he chaired. That was when I knew we had became a credible thought leader in this industry, even though we were a tiny company of 5 and had only been in market for 6 months. It opened my eye to the power of clear writing. Part of the reason I am writing this guide is to help me distill my own thinking and reflect on what my strength and weaknesses are as a PM. It’s been an incredibly rewarding experience to write it. I hope you’ll have an equally rewarding experience reading it.

Questions to ponder:

  • What are some of your favorite writing that you had read over the years? Why did you like them?

Readings:

Exercise: blog

  • Write about something you learned/find interesting once a week

Back to Top

Design

Design is one of those things that many people say is important, but not many people truly invest the time in. It is much more than just making things look pretty. It is about building a holistic solution to a problem that your users are having. It takes creativity to come up with the initial solution, but it also takes rigorous research and testing to validate those designs in the wild. It cannot be done in a vacuum.

When working with designers, I believe it’s important for PM to give feedback as much as possible and push the designer to show/test her work consistently. The cost of change during the design phase is 10x cheaper and faster than cost of change during development. Given that technical resource is typically the limiting factor in startup, prototyping and iterating on design quickly is key.

Questions to ponder:

  • What does good design mean for you? How do you know it’s good?
  • What are some ways you can test your design quickly?
  • How do you balance the wants/needs of design vs the reality of technology development and managing complexity?
  • How do you incorporate design into the product development process?

Readings:

Exercise: Design exercise

  • How would you design the following (draw mockups):
    • Alarm clock for heavy sleepers
    • Car for the blind
    • Others interesting scenarios you can think of

Back to Top

Business Strategy

Strategy is a very sexy word, mostly because that’s what you see executives or management consultants in fancy suits typically do. They are responsible for coming up with the “strategy” that the rest of the company then executes on. How they came up with it is often not talked about, but people seem to get paid a lot of money to do it…therefore it must be extremely hard. I want to take some time here to demystify the concept of strategy. Once you break it apart, it becomes incredibly clear what strategy is and isn’t.

In the marketplace, a business always has to evolve. Imagine that there are 2 points on a piece of paper. Point A is where the business is at currently. Point B is where the business wants to go. Usually, point B has more customers, more revenue, and more profit compared to point A. Now draw a line from point A to B. That line is the business strategy. A strategy is a way for a business to go from point A to point B. Now when you drew that line in your head, you probably instinctively drew a straight line. That’s the shortest path to point B and is in theory the best strategy. However, there are literally infinite ways to draw a line connecting point A and B, just like in the real world. There are infinite ways to approach a problem. The challenge is to get to point B in as straight of a line as possible.

To be clear, coming up with a strategy doesn’t mean you got to point B, simply that you identified a potential route. Execution is what actually gets you there. With that said, it is still important to understand strategy, because it’s a PM’s job to make sure your team is working on the right things. You are the guide, and a guide who doesn’t know how to get to the end destination is useless.

Questions to ponder:

  • Why do big companies fail when they have so much resources at their disposal?
  • In a battle for mobile dominance, why did google choose to open source android? How come Apple can’t do the same thing as Google?
  • If you were to disrupt your own company or the company you work for, what would you do?

Readings:

Exercise:

  • Pick a tech company that has recently been struggling (yelp, twitter, stripe). If you were the CEO, how would you try to turn it around? Make sure to write up your proposal.

Back to Top

Metrics and basic financial economics

It’s fairly obvious why understanding metrics is important. They provide valuable evidence that either supports or refutes your hypothesis. It forces you to be methodical about resource prioritization. It also allows you to communicate effectively with the rest of the “business”. A debate based on metrics is going to be much more productive than a debate based purely on opinions and assumptions. It allows people to check their egos at the door and have a healthy, productive conversation.

With that said, I want to stress that while metrics is important, lack of metrics should not and cannot paralyze you into inaction. By definition, if you wait until you have all the information, the opportunity is gone. If Elon Musk looked at the data at the time and said: “Batteries are too expensive, heavy, and hold little power, using a battery to power a car is a ridiculous idea.” then Tesla would have never came to be. There will be many times you will have to make decisions in the absence of data, and that’s totally fine.

Questions to ponder:

  • What are the key levers that drive your company’s business?
  • How do you expect it to change overtime? Is that a reasonable expectation?
  • If you were the CEO, what would you focus on over the next 12 months based on what you learned?

Readings:

Exercise: investment analysis

  • Pick a stock and build a case for why you should/should not invest in the company. Use data to back up analysis, including financial projections

Back to Top

Process

I’ll be the first to admit, I’m not really a process guy. I think they are important, but I tend to be a minimalist in this area. I try to keep a pretty open mind about process. My view is that different people like to work differently. Some people like to have more touchpoint and feedback. Others prefer to be left alone to just do their work. Some people like to think through the problem and solution alone and come back to the team to discuss. Other like to come up with a answer together in a more collaborative approach. They can all be equally productive, but need different process put in place to maximize their potential. The point is that process should be used to make the team more productive.

These days, most tech companies I know are either using agile or is transitioning to agile. In technology, the cost of change is low compared to traditional industries like manufacturing. As a result, it’s better to optimize for velocity. Agile processes are specifically designed to minimize communication overhead, thereby increasing speed and productivity. The readings below should get you a pretty good idea on how the process works. However, as I stressed in the beginning, view them as a template/starting point. Different teams will require you to finetune the process differently to get the most out of them.

Questions to Ponder:

  • Who are the typical stakeholders in a scrum? What do they do?
  • What is typically the process to roll out a new feature?
  • How do different product teams work together on larger projects?
  • How do you measure effectiveness of your process?

Readings:

Exercise:

Back to Top

Technology

One of the most common questions that gets asked about PM is “Do I have to know how to code?” The answer is no, you don’t need to know how to code. But is it going to help you become a better PM? Absolutely! The simplest way I can put it is that the top tech companies (i.e. google, facebook, amazon, dropbox etc.), who has access to the cream of the crop talent, wouldn’t hire product managers that can’t push code (at least that I know of). The reason is communication cost. Anytime the engineer has to come up a level and speak in “business” terms, the communication is less efficient. It’s much better if the PM can communicate in the same language as the engineers. Granted, finding people who are well versed in engineering as well as business is difficult. That’s why the starting salary for a PM role at those companies is $150k+.

There are a lot of links and readings in this section. It can be a bit overwhelming if you don’t come from an engineering background and never dealt with computers before. Just stick with it. There are tons of great resources out there to help you along. If you have a question, a quick google search will typically yield the answer you are looking for.

Questions to ponder:

  • How does data flow from your computer to the internet and then back to your computer? What systems does the data hit? What does each system do with the data?
  • How do one web application know how to talk to another web application?
  • How do you think machines and humans will interact with each other once general AI is achieved?

Readings:

Exercise:

Back to Top

Soft skills

This section covers the soft skills that are needed to thrive as a product manager. It focus more on effective communication, relationship building, time management, and a number of other areas. If mastered, those skills will take you from being a competent product manager to a great one.

Asking questions

This to me is an entire subject upon itself. Asking good questions is probably one of the most underrated and undervalued skill that a PM can have. Eric Schmidt, executive chairman of Google, once said, “We run this company on questions, not answers.” Asking good questions gets you new insights from your customers, which often uncover new opportunities for the business. However, throughout my entire career, people seem to just expects me to know how to ask questions, like it’s something that should come naturally. Make no mistake, asking good questions is a skill. It needs to be practiced and honed like any other skills.

As a PM, you are going to be spending a lot of time doing user interviews. The readings below should give you some good stock questions to start with. Luckily, this is a skill you will get to practice this a lot on the job. If you put your mind to it, you’ll get better really fast. If you are not currently a PM, then find every opportunity to learn and ask people questions. An interesting way to practice that someone suggested to me is to post questions on Quora and measure how good the questions are by the number and quality of the responses you get.

Questions to ponder:

  • What are some of the characteristics of a good question? a bad question?
  • Besides the way you phrase the question, what are other factors that could potentially impact the response you get from your subject?
  • The question “How are you?” is probably the most common question that get asked in any social interaction. Often the response is not very interesting (99% of the time, it’s “good and you?”). What are some other ways you can ask that question to elicit a more insightful response?

Readings:

Exercise

  • Listen to podcasts that you like and focus on the questions that the interviewer asks. If you don’t know what to listen to, I highly recommend the Tim Ferris show on iTunes. He ask some of the best questions to some really interesting people.
  • Post 1 question a day on Quora and evaluate the responses you get.

Back to Top

Working with others

An analogy i use quite often is that PM is similar to an amplifier in a sound system. By itself, it’s useless. Paired with the right speakers, power supply, and control unit, it’s the difference between a home theatre system and a sound system at a 20,000 people concert hall. Your ability to amplify your team’s output and impact will ultimately be what you are measured on. As a result, it’s important to understand how to best work with the people that are in the trenches with you everyday.

There are lots of generalizations in the readings below. However, I found that most of them do hold true based on my own experiences. Similar to the process section, use these as a guide and reference, not hard and fast rules.

Questions to ponder:

  • How are engineers and designers similar? How are they different?
  • How would you change the way you interact with your team?
  • Was there anything that stood out to you, or was unexpected?

Readings:

Exercise:

  • Experiment with at least one of the best practices suggested by the readings above and measure the impact over time.

Back to Top

On Productivity

PM is probably one of the most highly leveraged position at a company. You are constantly being pulled in different directions. One minute, you may be on customer support, the next you are gathering new requirements, until your engineers come to you with a blocking issue you must resolve. If you don’t have a systematic way to triage these requests, they can become overwhelming.

For me, I try to follow 3 simple rules:

  • Everyday, have 1 thing I must get done. I don’t go home until either it’s done or until I’m blocked.
  • Get in at least 1 hour ahead of my stand up to prep for my day. Those tasks may include answering emails, making sure requirements are in the system and all the tasks are up to date.
  • Take a 15 minute break every 2 hours. Go for a walk, play some ping pong, stare into space. Whatever I do, just don’t think about work. I find that this really helps refresh my mind.

In terms of day to day prioritization, there’s not really any hard or fast rules, but I use these heuristics as prioritization guides:

  1. Putting out fire: This include blocking issues from engineering or production bugs that significantly disrupt business operations.
  2. Tasks that must be done within the next 2 weeks: These are generally requirements gathering tasks to ensure that design and requirements stay between 1 to 2 sprints ahead of development.
  3. Other tasks with more flexible timelines: These generally are my research tasks. I usually have a list of key questions I want to answer and I take time to knock those out 1 by 1.

Questions to ponder:

  • What is your typical work day looks like?
  • What are some of your biggest time sinks in a typical work day?
  • How can you eliminate them?

Readings:

Exercise:

  • Experiment at least 1 recommendation from the readings above and measure the result over time.

Back to Top

Others

Below are some other resources that I found interesting, but didn’t really fit into any single categories. So I thought I would share it here.

Back to Top

15 thoughts on “A hitchhiker’s guide to product management”

    • Thanks Ian! Its great that you found it useful. Do you have any thoughts on other areas you think i should dig into more? I’ll definitely be updating the guide overtime, so let me know 🙂

      Reply

  3. Analytical Skills – understanding qualitative and quantitative data and how to tease out actionable insights. This becomes the most difficult (and rewarding) when metrics run contrary to user feedback but as you shorten iterative development cycles, your hypotheses can be refined to product-market-fit. Soft skills come into play when negotiating priorities across stakeholders.

    Reply

    • couldn’t agree more 🙂 In those cases I often just go with my best gut feeling and hope i’m right, especially if it’s something reversible. Finding out it’s a wrong decision quickly is better than indecision.

      Reply

  5. I would hate for your good insights to be discredited by missed punctuation, capitalization, and grammar errors. This is one space where the 20% will distract from the 80%. I would love to see your writing supported by a solid editor.

    The most distracting for me were:

    “What does a PM spends his/her day?
    What’s makes a good PM?”
    Do you mean “How does a PM spend his/her day?
    What makes a good PM?”

    You’re missing a period at the end of “Make sure to write up your proposal”

    You’ve not capitalized “absolutely!” and some companies that prefer their company name capitalized.

    I wish you and this article all the best, or would not have commented otherwise.

    Reply

    • Thanks. That is really totally fair. I’ll be the first to admit that my grammar/writing is still a work in progress, though the mistakes you pointed out are so basic I’m a little embarrassed. Already fixed the ones you pointed out, but will definitely go back and read through the post again to weed out the others.

      Can you recommend any good resources or tools that can help me become a better writer, particularly with grammar? English is not my first language and I never really learned grammar since coming to NA.

      Reply

      • I’m personally terrible at grammar myself, which is why I don’t hesitate to use an editor. If that’s not feasible, I would urge you at the point you are about to post to walk away, grab a bite to eat, call a friend, watch TV, whatever, just completely switch gears. Then, no earlier than half an hour later, read your post out loud. It will force you to slow down and catch a whole host of errors your “writing brain” doesn’t see.

        My uncle was a great writer and one bit of advice he gave me was “it will be brilliant at 3am. You will be realistic at 9am. Don’t publish anything your write at 3am. Wait until you sleep, then re-read the next day.” I’ve followed that one too.

        All the best.

Leave a comment